home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Network Support Library
/
RoseWare - Network Support Library.iso
/
mhs
/
v15b_n.exe
/
SYS.EXE
/
SMFUTIL.DOC
< prev
next >
Wrap
Text File
|
1992-01-07
|
38KB
|
825 lines
SMF Utilities
Overview
People who develop NetWare MHS applications and end-users which need a simple
application interface into NetWare will benefit from two utilities that are
part of the standard NetWare MHS 1.5 offering: SMFSEAL and SMFSEND. These
utilities submit SMF message in DOS files to NetWare MHS.
Developers of either NetWare MHS applications or gateways can use these two
utilities for testing whether the programs that they are writing submit
proper SMF messages to NetWare MHS. NetWare MHS administrators can use them
as a gateway.
SMFSEAL and SMFSEND provide a submission interface to NetWare MHS so that
NetWare MHS application and gateway developers can test their programs by
submitting messages to NetWare MHS by creating simple text files. The full
range of NetWare MHS services is available to developers via the
SMFSEAL/SMFSEND interface. SMFSEAL provides support for the SMF v64 format
used by NetWare MHS 1.1 while SMFSEND provides support for the SMF v70 format
used by NetWare MHS 1.5 and MHS 1.5C.
SMFSEAL and SMFSEND can also be used as a testing tool for submitting
messages to NetWare MHS or delivering messages to NetWare MHS local users.
SMFSEAL and SMFSEND are designed to be simple to use. At its most basic, they
are executed at the DOS command line. SMFSEAL and SMFSEND take as input DOS
files containing SMF messages and attachments. They submit the message to
NetWare MHS, and the developer can survey the results of that submittal.
Users of NetWare MHS also can utilize these utilities to provide a convenient
way of submitting NetWare MHS messages without the use of any particular
application. They can be used as a "gateway" by renaming them to INPOST.EXE
and putting them into the correct gateway file structure. (Note that if you
want to use both, you will need to define two different gateways.) All that
is needed is a text editor to prepare the file in SMF minimal submission
format which is described below.
SMFSEAL and SMFSEND optionally provide the facilities to return a message
file with a .ANS extension, which identifies the status of the sealing
operation.
Input Format Requirements
SMFSEAL and SMFSEND accept as input DOS files in the form of SMF messages.
Consult the SMF Programmer's Reference Manual for details concerning the
construction of SMF messages. The minimum fields SMF message header fields
required for submission to these programs are:
SMF-64 (SMF-70) Signature field
From: user1 @ wkgroup1 Author
To: user2 @ wkgroup2 Recipient(s)
<<CR>><<LF>> Blank line terminator
Note that the signature can be either SMF-64 for SMFSEAL or SMF-70 for
SMFSEND. Both will also accept a Control-C terminated by a linefeed character
only. Either form is equally acceptable. If the SMF-64/70 signature is used,
SMFSEAL/SMFSEND will replace it with a Control-C-linefeed signature in the
message that is constructed from the input file.
From the example input message shown, SMFSEAL/SMFSEND will construct a
message addressed to user2 @ wkgroup2. If user2 is a user at the local
NetWare MHS host, then SMFSEAL/SMFSEND will deliver the message to the user.
Otherwise, SMFSEAL will prepend a routing envelope to the message and submit
the message to NetWare MHS by writing the message file in the MV\MHS\MAIL\OUT
directory, while SMFSEND will perform message canonicalization and put the
message into the MV\MHS\MAIL\SND directory. (Message canonicalization is
described in the SMF Programmers Reference Manual.) If the message was
successfully processed and submitted to NetWare MHS (or delivered to a local
user), then the message is deleted from the directory where SMFSEAL/SMFSEND
found it. If SMFSEAL/SMFSEND could not process the message, then an error
return will be made. If NetWare MHS cannot process the message at all, the
message is left in the submission directory and renamed with a .BAD
extension. If the message can be canonicalized, but not submitted or
delivered, then the error report will be placed into a .AN0 file.
If SMFSEAL encounters multiple addresses (delimited by commas) in the To
field, SMFSEAL will deliver or submit a copy of the message to each such
address. Up to 30 comma-delimited addresses may be entered in the To field.
Including a Copies-to field in an SMF message submitted to SMFSEAL causes
SMFSEAL to include the Copies-to field in the message, and to generate copies
of the message to each address specified in the field. Up to 30
comma-delimited addresses may be placed in the Copies-to field.
SMFSEND follows the SMF v70 rules and allows up to sixty-four primary
recipients (To: header) and up to sixty-three secondary recipients (Copies-
to: or BCC: headers). Only one message will be generated generated to
multiple recipients at the same host. However, for both SMFSEAL and SMFSEND
at least one To: header or one Send-to: header must be used.
In addition to the required fields identified above, SMFSEAL and SMFSEND
will accept as input optional body text up to 16 KBytes in total length
(including message header), plus any other validly constructed SMF message
header field.
In particular, the following fields are useful in the basic repertory
of SMFSEAL and SMFSEND submissions:
Copies-to: u3 @ wg3, u4 @ wg4 Secondary recipients
Attachment-name: c:\docs\mydoc.doc Attachment filename
In-reply-to: 11A71725017B12F1 Message-id for replies
Send-to: Allows definition of specific
recipients
If an Attachment-name field is specified, then SMFSEAL/SMFSEND will include
the specified file as an attachment to the message being processed. The
original attachment file is not deleted after the message has been processed.
For SMFSEAL, only one attachment is allowed. For SMFSEND, up to sixty-four
attachments can be specified in the Attachment-name header. Each attachment
name is delimited by a comma.
For SMFSEAL, if a Send-to field is specified, identifying one to 30
comma-delimited addresses, then SMFSEAL will generate a copy of the message
to each recipient specified in the Send-to field, and will not generate
copies of messages to any address found in To and Copies-to fields. For
SMFSEND, the same rule is true except that the message can have up to sixty-
four names in the Send-to header.
SMFSEAL/SMFSEND Canonicalization Function
SMFSEAL and SMFSEND accept "minimal submission format" of SMF messages (only
signature, terminator, To and From fields present), and adds all other fields
required to make a canonically formed SMF message.
SMFSEAL/SMFSEND require as a minimum the following elements:
the SMF-64 (for SMFSEAL), or SMF-70 (for SMFSEND) signature (or
Control-C-linefeed signature for either)
a To field
a From field
a terminating blank line (<CR><LF>).
These elements are to be included in input files. If the input SMF file's
signature characters are SMF-64 or SMF-70, it will converted into the
signature to the SMF standard signature ^C<LF>. SMFSEAL/SMFSEND add any
header fields that are missing from the input message but that are required
to form a canonical format SMF message. SMFSEAL/SMFSEND will not modify or
replace the contents of any field that appears in the input message file
except for replacing an SMF-64 or SMF-70 signature with a ^C<LF> signature.
A canonical SMF message formed by either SMFSEAL or SMFSEND includes (at a
minimum) the following fields:
SMFSEAL SMFSEND
^C<LF> ^C<LF>
Sender: Sender:
Send-to: Send-to:
From: MCB-Options:
To: MCB-type:
Date: Hop-count:
Message-id: Date-posted:
<CR>><LF> SMF-Version: 70
From:
To:
Subject:
Message-id:
<CR><LF>
SMFSEAL
SMFSEAL accepts as input SMF 1.1 messages without routing envelopes. First,
SMFSEAL converts the message to canonical form, adding whatever fields are
missing to construct a valid canonical SMF message. Next, SMFSEAL attempts
local delivery if the intended recipient of a message is found to be a user
at the local host. Otherwise, SMFSEAL prepends a routing envelope to the
message, and submits the message to NetWare MHS by placing it in NetWare
MHS's MHS\MAIL\OUT message submission directory.
Installing SMFSEAL
SMFSEAL can be used in two different ways, for two different purposes:
as an automatic gateway submission process
as a command-line executable program.
SMFSEAL is placed in the \MV\MHS\EXE directory when NetWare MHS 1.5 is
installed. It can be used in the command-line format whenever it is required.
If you want to use it as a gateway, follow the steps in the next section.
Installing SMFSEAL as a Gateway
SMFSEAL can be installed as an automated submission process, invoked once for
every scheduled NetWare MHS cycle by the NetWare MHS Connectivity Manager.
To install SMFSEAL as an automatic gateway process on an existing NetWare MHS
host, do the following:
1. Locate the current NetWare MHS installation location. This is
identified by the DOS environment variable MV on the NetWare MHS
Connectivity Manager workstation. The MV environment variable
identifies the name of the drive and directory where the directory MHS
with all its subdirectories is located.
2. Create a directory called MV\MHS\MAIL\SMF. This directory is where
applications create and write files for submission to NetWare MHS.
3. Start the Directory Manager, logged in as the administrative user
of NetWare MHS. Select <routes to workgroups, hosts, and gateways> from
the Directory Manager main menu. Select <Add entry>, and from the menu
that appears select <Define a gateway>. In the menu entitled <A
GATEWAY>, set <Host name:> as <SMFSEAL>, and press <Enter>. For
<Description:> type <SMFSeal gateway>. For <Version> enter 64, and
press <Enter>. You do not need to enter anything for <Gateway
commands.> Optionally, you can enter <V> into the gateway's <Gateway
Commands> menu entry. This will cause SMFSEAL to display the results of
its operations. Running SMFSEAL in this mode of operation will visually
disrupt the display made in the NetWare MHS Routing Activities screen;
however, there are no negative processing consequences to this mode of
operation.
4. Select <Done> to complete the gateway definition.
5. Exit from the Directory Manager, and then from NetWare MHS
altogether.
6. Copy the file SMFSEAL.EXE from the \MV\MHS\EXE directory to the
directory MV\MHS\MAIL\GATES\SMFSEAL\PUBLIC, giving SMFSEAL the filename
INPOST.EXE. For example:
copy f:\mhs\exe\smfseal.exe f:\mhs\mail\gates\smfseal\public\inpost.exe
7. Start NetWare MHS. Once every scheduled cycle, NetWare MHS will
invoke the SMFSEAL gateway, running INPOST.EXE, which is really
SMFSEAL.EXE. When SMFSEAL is called in this way, it will SMFSEAL every
file without an extension in the directory MV\MHS\MAIL\SMF.
Note that SMFSEAL returns an exit errorlevel code of 1 if it finds nothing to
seal. The NetWare MHS gateway processor displays an error report <Inpost
Failed> whenever an Inpost process returns an exit code other than 0.
Therefore, when SMFSEAL is run as a gateway process, NetWare MHS will display
the <Inpost Failed> error message every time the gateway process is run and
there are no messages to seal. This is a normal condition for gateway
operation of SMFSEAL.
SMFSEAL Command Line Syntax
The command line syntax for SMFSEAL is:
smfseal {[-Fpathname|-Ddirectory_name]} {-Q} {-T} {-ODirectory}
{-ADirectory} {-Sserial#} {-V}
-F Filename (or full pathname of file) to SMFSEAL (must have no
filename extension). Wildcards are acceptable.
If the -F switch is omitted, then SMFSEAL attempts to SMFSEAL all
files without extensions in directory MV\MHS\MAIL\SMF. Note that
SMFSEAL will attempt to process any file in that directory
without an extension even if it is not an SMF file. The
processing will fail and the file will be renamed with a .BAD
extension.
-T If the -T switch is present, then SMFSEAL does not attempt to put
the SMF into canonical form. If the in-transit SMF cannot be
built from supplied fields, then the SMF message is renamed with
a .BAD extension.
-Q If the -Q switch is present, then SMFSEAL does not delete the SMF
input file, but instead renames the file with a .ANS extension
and places Send-to, Error-report, and Submission-report fields on
the top of the SMF (under the ^C<LF>) indicating the result of
the sealing operation.
The message header in the .ANS file is written in the format of
the message as it was submitted to NetWare MHS (or delivered to
a local user). Thus, any fields added to the message header when
SMFSEAL puts the message header into canonical format will appear
in the .ANS error reports that correspond to particular
exceptions. See SMFSEAL Error Codes, later in this documemt, for
a discussion of these exceptions and the error reports associated
with each exception.
-O The -O switch lets the user specify a destination directory where
SMFSEAL is to write the SMF messages it constructs.
This option lets the user force submission or delivery to a
gateway, or to prohibit local delivery (by specifying
MV\MHS\MAIL\OUT for this switch).
-A The -A switch lets the user specify a destination directory where
SMFSEAL will copy attachment files associated with SMF messages.
Use A in conjunction with -O to force submission or delivery to
gateway or test directories.
-S The -S switch allows the user to specify a serial number for
generating a UID, so that serial number violation strategies can
be tested. If this switch is omitted, SMFSEAL uses the serial
number from NETDIR.TAB.
-V If the -V switch is present, then SMFSEAL displays to STDOUT the
result of each attempt to SMFSEAL a file, and then displays to
STDOUT the exit return code.
SMFSEAL ignores all command line arguments after the -D or -F, -Q, -T, and -V
switches, as long as they are not preceded by a hyphen. This allows
installation of SMFSEAL as a gateway if it has been renamed to INPOST.EXE.
SMFSEAL performs local delivery. An NetWare MHS workstation is not required
for delivery of SMFSEALed messages to local users to occur.
SMFSEAL Error Codes
SMFSEAL Errorlevel Return Codes
SMFSEAL returns errorlevel exit as described in the list below.
Errorlevel Message
0 Files were found to SMFSEAL
1 No files were found to SMFSEAL
50 Bad or illegal filename specified to SMFSEAL in -F
switch or bad, illegal, or nonexistent directory
specified in -D switch
51 Invalid serial number in -S switch
52 Environment error (date not set, MV not found or not
pointing to NetWare MHS directories)
255 All other errors
SMFSEAL Error-Report Codes
An Error-report field under the ^C<LF> will indicate the general status of
the SMFSEAL operation. The following error reports can appear:
0 Message could be sealed. All intended recipients
were sent copies of the message.
1 Message could be sealed. One or more of the intended
recipients could not be sent a copy of the message.
2 Message could not be sealed. The recipient address
list could not be parsed.
3 Message could not be sealed. One or more required
header fields are missing.
12 Invalid size of message (message, or one or more
message header fields are too large to process)
14 Unknown options requested
15 Illegal application name in From, Sender, or
Application-name fields
16 Illegal originating user name in From or Sender
fields
17 Illegal workgroup (or host) name in From or Sender
fields
20 Invalid message subject
21 Invalid filename in Attachment-name field (or
specified file not found)
22 Invalid message ID specified in Message-ID field
23 Invalid message ID specified in In-reply-to field
24 Invalid date in Date field
28 Missing blank line after message header
52 Unable to create NetWare MHS storage file for
attachment (out of space, out of directory entries,
required directory not found, or rights not
assigned)
53 Unable to create NetWare MHS storage file for
message (out of space, out of directory entries,
required directory not found, or rights not
assigned)
255 Unknown error
Submission Report Codes
A Submission-report field will appear under the Error-report field if the
Error-report is 1. The Submission-report field will indicate the status of
submission for each recipient in a comma-delimited list of numbers, matching
one-for-one the addresses in the Send-to field. The following submission
reports can appear:
0 Successful submission for this recipient
18 Illegal destination username or application name for
intended recipient
19 Illegal destination workgroup (or host) name for
intended recipient
101 Unknown user (local delivery)
102 Unknown application for recipient user (local
delivery)
105 Missing attachment during delivery
130 Could not create file for local delivery of message
131 Could not create file for local delivery of
attachment
255 Unknown error
Note: The Send-to field under the at the top of the message will appear in
the form of a comma delimited list of all recipients of the message to which
SMFSEAL sent a copy of the message.
SMFSEND
SMFSEND accepts as input SMF v70 messages. It also performs the
canonicalization of the message and attempts to do local delivery. If the
user is remote, it places the message into the MV\MHS\MAIL\SND directory for
processing by the Connectivity Manager.
SMFSEND is placed in the MV\MHS\EXE directory when NetWare MHS 1.5 is
installed. It can be used in the command-line format whenever it is required.
If you want to use it as a gateway, follow the steps in the next section.
Installing SMFSEND as a Gateway
SMFSEND can be installed as an automated submission process, invoked once for
every scheduled NetWare MHS cycle by the NetWare MHS Connectivity Manager.
To install SMFSEND as an automatic gateway process on an existing NetWare MHS
host, do the following:
1. Locate the current NetWare MHS installation location. This is
identified by the DOS environment variable MV on the NetWare MHS
Connectivity Manager workstation. The MV environment variable
identifies the name of the drive and directory where the directory
NetWare MHS with all its subdirectories is located.
2. Create a directory into which you will place the SMF 70 files. This
directory is where applications create and write files for submission
to NetWare MHS. Note that unlike SMFSEAL, SMFSEND has no default input
directory.
3. Start the Directory Manager, logged in as the administrative user of
NetWare MHS. Select <routes to workgroups, hosts, and gateways> from
the Directory Manager main menu. Select <Add entry>, and from the menu
that appears select <Define a gateway>. In the menu entitled <A
GATEWAY>, set <Host name:> as <SMFSEND>, and press <Enter>. For
<Description:> type <SMFSend gateway>. For <Version> enter 70, and
press <Enter>.
You must put a -F command in for <Gateway commands>. The -F command
will have the name of the directory you created for the SMF files. (For
example, if you created the directory F:\SMFSEND for the SMF files, you
would add the gateway command as -FF:\SMFSEND).
Optionally, you also can enter -V into the gateway's <Gateway Commands>
menu entry. This will cause SMFSEND to display the results of its
operations. Running SMFSEND in this mode of operation will visually
disrupt the display made in the MHS Routing Activities screen; however,
there are no negative processing consequences to this mode of
operation.
4. Select <Done> to complete the gateway definition.
5. Exit from the Directory Manager, and then from NetWare MHS
altogether.
6. Copy the file SMFSEND.EXE from the MV\MHS\EXE directory to the
directory MV\MHS\MAIL\GATES\SMFSEND\PUBLIC, giving SMFSEND the filename
INPOST.EXE. For example:
copy f:\mhs\exe\smfsend.exe f:\mhs\mail\gates\smfsend\public\inpost.exe
7. Start NetWare MHS. Once every scheduled cycle, NetWare MHS will
place invoke the SMFSEND gateway, running INPOST.EXE, which is really
SMFSEND.EXE. When SMFSEND is called in this way, it will process every
file with no extension in the directory you created for the SMF files.
Note that SMFSEND returns an exit errorlevel code of 1 if it finds nothing to
seal. The NetWare MHS gateway processor displays an error report <Inpost
Failed> whenever an Inpost process returns an exit code other than 0.
Therefore, when SMFSEND is run as a gateway process, NetWare MHS will display
the <Inpost Failed> error message every time the gateway process is run and
there are no messages to seal. This is a normal condition for gateway
operation of SMFSEND.
Differences Between SMFSEND and SMFSEAL
SMFSEND 1.5 will perform the same services as SMFSEAL with the following
differences:
if -F parameter is omitted, SMFSEND 1.5 will process the working
directory. Care must be taken if the -F parameter is omitted since
SMFSEND will attempt to process ALL files with no extension in the
working directory as SMF files. If non-SMF file is present, SMFSEND
will try to canonicalize it, fail, and then rename the filename with a
.BAD extension.
Also, the MV\MHS\SND directory should not be as the working directory
when -F is omitted, since SMFSEND will recursively canonicalize
messages that have already been canonicalized.
Submission of messages found not to be local users is to MHS\MAIL\SND
in a v70 format, not MHS\MAIL\OUT in a v64 format.
If a Conversation-ID field that has a blank value is submitted to
SMFSEND, SMFSEND will fill the Conversation-ID field with a value that
is the same (except for type code) as the Message-ID it has generated
or has found in the message's header.
The canonicalize function from NetWare MHS 1.5 replaces the
canonicalize function used in SMFSEAL v1.1.
Multiple attachment v70 submission is supported.
Multiple recipient single instance v70 submission is supported.
V70 to V64 conversion, including bursting of multiple attachment
messages is supported for local delivery to users of v64 applications.
SMFSEND processes SMF messages, reading the SMFs from a source directory,
adding missing but required SMF header fields, and writing canonical
submission version 70 SMF messages (canonicalized except that no MHS-ID field
is generated) into the workstation MV's MHS\MAIL\SND (and MHS\MAIL\PARCEL)
directory, (or performing local delivery of fully canonicalized delivery SMF
messages with an MHS-ID if a recipient can be identified is a local user).
SMF files processed by SMFSEND must have no filename extension. They may
appear in any format from minimal submission through fully canonicalized.
SMFSEND success and failure actions
If the SMF has been SMFSealed successfully, the SMF is deleted
from the source directory.
SMFSEND will fail if:
the canonicalize process fails,
if required files or directories are not found,
if insufficient rights to required files or directories are granted,
if NetWare MHS cannot be located, or
if a user is determined to be local but delivery could not be
performed.
If a -Q switch has been specified and no errors are found, then SMFSEND
creates a file with the same pathname as SMFSEND's input file but with a .ANS
extension, which includes the fully canonicalized message header produced by
SMFSEND. This will be the same as the file placed into the MV\MHS\MAIL\SND
directory.
If an error occurs, SMFSEND distinguishes between the case of an ill-formed
message versus a message that is well-formed but incorrect.
In the first case, the message file either cannot be recognized as an SMF
file or is missing the required minimum headers (ie Signature, To, From and
closing blank line) or the named attachments are missing. Running SMFSEND
will result in the message file being renamed with a .BAD extension and the
error code being written to STDOUT. If the -Q switch is specified, then in
addition the error-report is placed into the .ANS file. This file contains a
^C<LF> signature and 22Error-report header with the error number.
In the second case, the message might be able to be at least partially
canonicalized, but SMFSEND is not able to process it further. An example is
a recipient with no workgroup name. The file will be deleted and the error
report written to STDOUT. Specifying the -Q switch will result in addition to
the .ANS file having the canonicalized message with the error report
appearing in a file with a .AN0 extension with a text description of the
error.
Values for the Error-report are specified are the same as the error messages
for delivery and non-delivery which can be found in the Troubleshooting
appendix of the NetWare MHS Installation and Configuration Guide.
If attachment(s) are specified in an Attachment-name field of the input SMF,
then SMFSEND sends the specified attachments (if they exist), but does not
delete the attachment files.
If the specified attachment file does not exist and the -Q switch was not
used, then SMFSEND renames the input SMF message file with a .BAD extension
and prints the error message to STDOUT. If -Q was specified, the message file
is still renamed to .BAD, but the error report is placed into the .ANS file.
SMFSEND command line syntax
The command line syntax for SMFSEND is:
SMFSEND {-Fpathname} {-Q} {-Sserial#} {-V}
-F Filename (or full pathname of file) to SMFSEND
-Q If the -Q switch is present, then SMFSEND creates an
"answer" file with a .ANS extension using the same pathname
as the submitted SMF. Errorcodes are specified either in
the .ANS file if the message file is renamed to .BAD
otherwise in the .AN0 file. (See Appendix B of the
Installation and Configuration Manual for a list of error
codes.)
-S The -S switch allows the user to specify a serial number
for use in UID generation, for purposes of testing serial
number violation strategies. If this switch is omitted,
SMFSEND uses the serial number from NETDIR.TAB.
-V If the -V switch is present, then SMFSEND displays the
result of each attempt to SMFSeal a file to STDOUT, and
then displays the exit return code to STDOUT.
SMFSEND ignores all command line arguments after the -F, -Q, and -V switches,
as long as they are not preceded by a hyphen. This allows installation of
SMFSEND as an INPOST.EXE gateway process.
SMFSEND performs local delivery. An NetWare MHS workstation is not required
for delivery of SMFSENDed messages to occur. Delivery is performed in
version 64 or version 70 format as appropriate to the recipient's
application.
SMFSEND must determine which recipients in a recipient list are local, and
attempt local delivery for those, and write an canonicalized message file
referring to the remaining recipients to the MV\MHS\MAIL\SND directory for
later processing by NetWare MHS.
SMFSEND Errorlevel Exit Codes
SMFSEND returns the following errorlevel exit codes when it is done
processing:
Errorlevel Return Codes
Errorlevel Message
0 Files processed without error
1 No files were found to process
50 Bad or illegal directory specified to the directory
specified via the -F switch
52 Environment error (date not set, MV not found or not
pointing to NetWare MHS directories)
255 All other errors
Required SMF fields, and the SMFSEND "Canonicalize" function
SMFSEND requires the following SMF header fields:
SMF-70
To: to_user
From: from_user
<blank line>
Optional body text may appear after the blank line terminating the SMF
message header.
SMF message header lines may be terminated by either <LF> or by <CR><LF>.
The first line may be "SMF-70", "SMF-64", or ^C<LF>. SMFSEND replaces any of
these with ^C<LF> during its canonicalization process.
If only the minimum complement of SMF fields is found by SMFSEND, it will
perform NetWare MHS 1.5 canonicalization, except that no MHS-ID field is
generated. (For more information about SMF 1.5 Canonalization, see the SMF
Programmers Guide.)
If a Conversation-ID field that has a blank value is submitted to SMFSEND,
SMFSEND will fill the Conversation-ID field with a value that is the same
(except for type code) as the Message-ID it has generated or has found in the
message's header. If a Conversation-ID field with a legal value is found in
a submitted SMF message, then SMFSEND will include it in the canonicalized
SMF. Otherwise, no Conversation-ID field will appear in a message processed
by SMFSEND.
Optional SMF fields
SMFSEND will accept the same optional fields as NetWare MHS 1.5 and its
canonicalization procedure do.
Attachments may be associated with a message by specifying an Attachment-name
field specifying one to 64 full or relative pathnames for files, or may be
associated with a message by including an Attachment field specifying one to
64 attachment files that have been copied to the MV\MHS\MAIL\PARCEL
directory. If the Attachment field is used, the Attachment-name field is
optional, and the string it contains can be a filename without path
information. If the Attachment field is used, SMFSEND does not move any
attachment files, since they are already presumed to be in the proper
submission directory, however SMFSEND verifies that there are files with the
specified names in the parcel submission directory, and fails if it does not
find them. Note that using the Attachment-Name header rather than an
Attachment header simplifies the process of specifying attachments in that
SMFSEND does the work of creating the temporary files in the PARCEL
directory.
Attachment files specified to SMFSEND are not deleted after sealing.
If no Send-to field is encountered, SMFSEND will submit a message for each
addressee specified in the To, Copies-to, and BCC fields, creating a Send-to
field in each message corresponding to the recipient specified in that
message's routing envelope. If a BCC field is used, it is deleted by SMFSEND
after addresses specified in the field have been added to the canonicalized
SMF's Send-to field.
If a Send-to field is specified, it may contain either a single address or a
list of comma delimited addresses. If a Send-to: field is encountered,
SMFSEND will send a copy of the message to only those recipients whose
address appears in the list, regardless of what addresses may appear in other
header fields.
Use of a Send-to field allows a second method of specification of blind
recipients, since Send-to addressees do not need to appear in any other SMF
header fields. Note that use of a Send-to field in an SMF that is processed
by SMFSEND requires the specification in the Send-to field of EVERY recipient
of the message for which SMFSEND is to generate.
If the -Q switch is selected, and multiple recipients are specified, then the
.AN0 file includes an error-report field specifying disposition of the
message to each recipient which was specified incorrectly. The .ANS will
contain the canonicalized message with recipients in Send-to set to those
which were correctly specified. The corresponding message file appears as
well in the MV\MHS\MAIL\SND directory.
Using SMFSEND as the Submission Engine
Another use for some applications is to use SMFSEND as the means for
submitting messages to NetWare MHS. This allows the application developer to
create minimal submission messages and pass off the work of canonicalization
and local delivery to SMFSEND.
Tests on SMFSEND performance show that it requires about 150K bytes of RAM.
To start the program, three or four seconds are required and each message to
be processed takes about half second per message. (If a message has many
attachments and/or many headers, the timing will be longer.)
Examples
The following are examples of typical SMF messages that can be submitted to
SMFSEND.
Simple Message
SMF-70
From: user1 @ wg1
To: user2 @ wg2
<CR><LF>
Optional body text of the message goes here.
This example illustrates the simplest form of message that can be submitted
to SMFSEAL/SMFSEND. Note that the subject will be <None> when the message is
canonicalized.
Message with Recipients of Message Copies
SMF-70
From: user1 @ wg1
To: user2 @ wg2, user3 @ wg3
Copies-to: user4 @ wg4, user5 @ wg5
<CR><LF>
Optional body text of the message goes here.
This example illustrates multiple recipients for the message. Two recipients
have been specified as the primary recipients of the message, and two others
have been specified as recipients of copies of the message. SMFSEND will
attempt to deliver locally or submit to NetWare MHS a copy of this message to
each recipient identified in the To and Copies-to fields. SMFSEND will take
advantage of NetWare MHS multiple-recipient functionality.
Message with an Attachment File
SMF-70
From: user1 @ wg1
To: user2 @ wg2
Attachment-name: f:\docs\mydoc.doc
<CR><LF>
Optional body text of the message goes here.
This example illustrates sending an attachment with a message.
SMFSEAL/SMFSEND attempt to send the file F:\DOCS\MYDOC.DOC with this message.
If successful, then a copy of the file is sent with the message. If the
specified file cannot be found or opened for reading, then they will rename
the message file with a .BAD extension, and the message is not sent. Note
that SMFSEND will allow multiple attachments to be specified with this
header.
Message Composed as a Reply to Another Message
SMF-70
From: user1 @ wg1
To: user2 @ wg2
In-reply-to: 11A71725017B12F1
<CR><LF>
Optional Body Text of the message goes here.
The application sending this reply message has copied the Message-id of the
message to which the reply is made into the In-reply-to field of the reply
message.
Message with Blind-Copy Recipients
SMF-70
Send-to: user2 @ wg2, user3 @ wg3, other @ recip
From: user1 @ wg1
To: user2 @ wg2
Copies-to: user3 @ wg3
<CR><LF>
Optional body text of the message goes here.
This example illustrates the use of an explicit Send-to field in a message
submitted to SMFSEAL. A copy of the message will be sent to all addresses
found in the Send-to field. Note that each recipient identified in the To and
Copies-to fields are repeated in the Send-to field. Any recipients specified
in the To or Copies to fields but missing in the Send-to field will not
receive copies of the message. Note also that the addressee other @ recip is
a blind-copy recipient, who is not identified as a recipient to any other
recipient of this message. Note that for SMFSEND, the header BCC: could have
been used instead.